(1) Field of the Invention
The present invention relates to a multicast network in which a source server of a multicast packet is specified and, more particularly, to a technique for connecting a client node which does not have a function of designating a source server of a multicast packet to a multicast network.
(2) Description of the Related Art
Multicast is a technique of transmitting packets simultaneously to a plurality of destinations on the Internet. The multicast enables distribution of a large amount of information to a plurality of destinations with a smaller amount of packets as compared with the case of transmitting packets to respective destinations a plurality of times. Consequently, the multicast is particularly suitable for real-time multimedia communication requiring heavy traffic typified by streaming and a video conference.
However, a multicast network is not spread so much in today's world. One of the main reasons is complexity of multicast routing control. Although multicast routing protocols such as DVMRP (Distance Vector Multicast Routing Protocol: RFC 1075) and PIM-DM (Protocol Independent Multicast-Dense Mode: draft-ietf-pim-dm-new-v2-01.txt) are simple, multicast traffic flows also into segments which are the units constructing a network and do not need multicast traffic, so that the protocols have a drawback of low efficiency in a network utilization.
In operation of a multicast network, PIM-SM (Protocol Independent Multicast-Sparse Mode: RFC 2362) which overcomes the drawback is usually used. According to PIM-SM, multicast traffic is allowed to flow only to the minimum segments. However, since overhead for calculation of a multicast transmission tree is large, PIM-SM has problems such that the protocol is complicated. Therefore, it is difficult to carry out the protocol, and a load on a router is heavy (Asaeda, “New Communication Architecture by Source Specific Multicast”, Information Processing, March, 2002, Vol. 43, No. 3, pp. 260-265).
One of promising techniques proposed to address the complexity is source-specific multicast. In conventional N-to-N multicast communication, a multicast receiving terminal transmits a request to join a multicast group. In the source-specific multicast, when a multicast receiving terminal sends a request to join a multicast group, it is necessary to designate the source address of a multicast packet. The designation of the multicast source address by the multicast packet receiving terminal aims at limiting a packet forwarding process to one-to-N multicast communication to make the multicast routing control simpler (draft-ietf-ssm-overview-00.txt) Considering that many of cases of applying multicast are streaming from a small number of servers, even if the packet forwarding process is limited to one-to-N communication, the user needs for multicast can be satisfied.
A principal difference between source-specific multicast routing control and conventional general multicast routing control is that, in the source-specific multicast routing control, when an end user terminal joins a multicast group, the address of a source server of a multicast packet have to be designated together with the address of the multicast group. To join the source-specific multicast network, the end user terminal has to support a multicast group management protocol adapted to the source-specific type, for example, IGMPv3 (Internet Group Management Protocol Version 3) in IPv4 or MLDv2 (Multicast Listener Discovery Version 2) in IPv6.
However, at present, the number of terminals supporting IGMPv3 or MLDv2 is not large. Since the cost of IGMPv3 or MLDv2 is higher than that of a conventional any-source multicast group management protocol, these multicast group management protocols are estimated that the possibility of actual implementation to low cost terminals typified by network appliances are also low in future. Consequently, some techniques for accommodating terminals, each of which does not support IGMPv3 or MLDv2 as the source-specific multicast group management protocol, to a source-specific multicast network have been proposed.
For example, in IGMPv3 Lite of Cisco Systems, Inc., by implementing an IGMPv3 translation library having specified function in an application of an end user terminal, the end user terminal can join a source-specific multicast network via the translation library even when the application of the end user terminal does not actually support IGMPv3. In URD (URL Rendezvous Discovery) of Cisco Systems, Inc., the end user designates the address of a multicast source server to a router with HTTP (Hyper Text Transfer Protocol), so that a request to join a source-specific multicast network can be notified to the router even when the end user terminal and application do not support IGMPv3.
Except for those conventional techniques, by allowing a router itself to make a line to statically join a multicast group including a specified multicast source, multicast traffic from the specified source can be flowed to the line even when an end user terminal on the line does not support IGMPv3 (Cisco Systems, Inc.: “Source-Specific Multicast with IGMPv3, IGMPv3 Lite, and URD feature module, Release 12.1 (5)T”.
One of advantages of the source-specific multicast is that by permitting only a multicast transmission from a specific source, network resources can be prevented from being wasted by multicast transmission from an unspecified source. As one of proposals for improving the source-specific multicast from such a viewpoint, there is multicast routing protocol (draft-lehtonen-magma-mcop-00.txt) proposed by Lehtonen of Sonera Corp.
In this system, upon receiving a request to join source-specific multicast, a multicast forwarding equipment inquires a multicast control server of whether joining is possible or not, so that the multicast control server can manage the filtering of requests to join the source-specific multicast.